Swift Stories

If you’ve developed apps for the Apple ecosystem, you’ve probably noticed how isolated the developer experience is—both in time and space. Everything is scoped tightly to the local environment where a specific action happens. You build an app, and you see it running right there in the simulator. But getting it to escape that environment—into a more collaborative or automated context—requires a lot of plumbing.

Let’s say you’ve already run the same compiler instructions your colleague needs. You should be able to help them skip redundant work and speed things up. But in Apple’s ecosystem, you can’t. There’s no shared context, and that has a real, negative impact on the developer experience.

When you compare this to other ecosystems—those that take a more global and integrated approach to development—you start to see what’s missing. Development isn’t just about turning ideas into code and passing that through a compiler. It’s also about shaping solutions collaboratively and building tools and workflows around that collaboration. Whether it's Figma for design, GitHub for code, or Slack for communication, these are all places where development happens. But Xcode and Apple’s toolchain behave as if these tools don’t exist. That leads to a mess of indirections—juggling things through CI or external scripts just to make the tools talk to each other.

That indirection kills what should be magical. Ideally, you’d click a button, your process integrates with GitHub, and the next time you open a PR, you're told whether you’ve introduced a regression in bundle size. But to get there, you often need to work around the constraints of the Apple toolchain.

This local focus isn’t just spatial—it’s also temporal. Improving your development environment and your apps requires more than just inspecting isolated actions or artifacts. Seeing a single test fail isn’t helpful. But seeing that the same test produces inconsistent results over time? That tells you it’s flaky. Or take build times: a 3-second increase might seem fine in isolation, but if it's a deviation from the usual trend, that change might warrant a second look before merging to main.

To catch these patterns, you need standardized data (not just .xcresult files), the right storage and querying infrastructure, and timely feedback in the right places—like a PR comment flagging a build-time regression, or a Slack report pointing out the most flaky tests of the day.

I like to think of this as a missing layer of developer services. Apple’s services mostly focus on publishing apps. The tools focus on building them. But there’s very little focus on improving the health of your codebase and dev environment. And because of that, teams often have to build this themselves. Most tools inherit the same local mindset—probably to avoid asking teams to run a server with a proper database and API to collect and surface these insights.

I was hopeful when Apple acquired BuddyBuild, but that promise faded. They folded it into yet another locally-scoped feature inside Xcode—throwing away some of the most compelling ideas around CI and dev tooling.

Will Apple ever shift this mindset? It’s hard to say. But one thing is clear: this gap needs to be bridged. That’s why we’re investing in the infrastructure and analytics to give teams real visibility into their development process. Because development doesn’t happen in isolation—it’s collaborative, continuous, and evolving. And only by embracing that can we deliver a truly great developer experience.

The content has been written by a human and the grammar reviewed with ChatGPT 4o

Food for thought